Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

La grogne monte contre VMware (Broadcom) : AT&T, Orange et Thales vont en justice

La grogne monte contre VMware (Broadcom) : AT&T, Orange et Thales vont en justice

Le 20 septembre à 16h01

Le début de cette histoire remonte à mai 2022, quand Broadcom rachète VMware pour 61 milliards de dollars. Un investissement qu’il faut visiblement rentabiliser au plus vite pour Broadcom, qui passe à l’offensive avec une réorganisation complète des gammes et des hausses importantes de tarifs.

Comme nous l’avons récemment détaillé, AT&T a décidé de contre-attaquer et de déposer une plainte pour que VMware honore ses contrats signés avant son rachat, sans même réclamer de dommages et intérêts.

Thales était aussi passée à l’offensive, comme l’expliquait en août L’Informé. Les reproches sont les mêmes que ceux d’AT&T : de nouvelles offres tarifaires imposées, alors que la société « avait signé un contrat en 2022 avec VMware valide jusqu’en mars 2025 à des conditions différentes ».

Thales avait saisi le tribunal de commerce de Paris en référé pour que l’ancienne offre reste applicable. Toujours selon nos confrères, la société a obtenu gain de cause. Le jugement sur le fond est attendu pour la fin de l’année.

Toujours selon L’Informé, c’est maintenant au tour d’Orange d’assigner « en référé devant le tribunal de commerce de Paris l’éditeur de logiciel ». L’affaire est toujours en cours. Orange « accuse le groupe américain de rupture brutale des relations commerciales », selon nos confrères.

En avril, le Cigref (avec Beltug en Belgique, CIO Platform Nederland aux Pays-Bas et Voice en Allemagne) était déjà monté au créneau pour condamner « fermement le comportement de Broadcom sur le marché ». L’association, qui regroupe de grandes entreprises françaises, appelait « la Commission européenne à prendre les mesures qui s’imposent ».

Le Cigref ne mâchait pas ses mots : « Il est indispensable en effet d’empêcher la ponction financière exorbitante, illégitime et stérile que Broadcom s’apprête à commettre au détriment de l’économie européenne, et de dissuader d’autres fournisseurs de s’engager à l’avenir dans des comportements aussi peu éthiques que ceux de Broadcom ».

Le 20 septembre à 16h01

Commentaires (35)

votre avatar
Tema le rat !
votre avatar
Au top, la stratégie de broadcom.
How could this go wrong?
votre avatar
"Ah ! Les joies des logiciels privateurs !" nous dirait Stallman.
votre avatar
Si ça pouvait pousser les entreprises à conteneuriser massivement, on en ressortirait grandit. 95% du compute que je vois en entreprise pourrait être conteneurisé et pourtant il y a tjrs des masos pour faire tourner ça dans des VMs. Certainement par plaisir de se taper le patch management et l'administration système (et j'ai été ingé sys linux pdt 10 ans).
votre avatar
Hum moui mais non.

Conteneuriser pour conteneuriser c'est pas c'est l'idée du siècle.

Entre entre avoir à maintenir un clusteur kubernetes / openshift dont les images des conteneurs client sont en gros le contenu d'une VM et maintenir de bêtes VM LAMP ... Je préfère encore la solution VMs.
votre avatar
Ajouté à cela que l'image aussi doit suivre un cycle de patch management. Les containers c'est à peu près autant d'emmerdes que les VM, surtout quand la workload n'est pas pensée pour. La VM dans de la VM, bof.
votre avatar
Il est clair que pas mal d'entreprises n'ont absolument pas la maturité pour avoir du container. Si c'est fait correctement il y a moyen que ce soit beaucoup moins d'emmerdes que les vm's, mais ça demande des processus matures, une automatisation adaptée et une approche CI/CD suffisante. Mais d'expérience, il y a beaucoup d'entreprises où les managers sortent l'idée de passer à Openshift/Tanzu/EKSE/Mirantis/... de leur cul et ensuite ne font pas les réformes nécessaires pour que ça se passe bien, ce qui fait que les devs et les utilisateurs se prennent les inconvénients de kubernetes sans en goûter les avantages.
votre avatar
Le cycle d'une image c'est la golden + le runtime, la VM c'est ça + toute la partie système. Dire que c'est autant d'emmerdes, c'est mathématiquement faux
votre avatar
Je ne fais que relater l'expérience opérationnelle. Prêcher la containerisation pour faire la containerisation, sans analyse de faisabilité avec la workload amène à des antipatterns dégueulasses en matière de sécurité.

Du genre figer les versions des middlewares à l'intérieur du container "parce que ça marche comme ça et le projet n'a pas de budget pour intégrer les changements". Ben ouais, on préfère faire de la feature et non de la MEV, c'est plus sexy à vendre auprès des décideurs ou des clients. En dehors des contextes qui doivent gérer des contraintes réglementaires fortes, d'autres restent pilotés par le métier qui n'a aucune connaissance de l'IT et la voit comme une charge dont il faut réduire le coût.

La solution miracle, ça n'existe pas, et il ne faut surtout pas la voir par l'unique prisme de la technique.
votre avatar
C'est pas par plaisir de faire de la conteneurisation et tout l'accompagnement du changement qui va avec mais par gain de productivité, argument le plus puissant pour le business.

Le problème que tu évoques de non-suivi du middleware n'a rien à voir avec le sujet de conteneurisation puisque la problématique est strictement la même en virtualisation.

Je ne dis pas qu'il faut TOUT conteneuriser car on ne le pourrait pas ne serait-ce que techniquement et que, comme tu l'évoques, il y a parfois des contraintes qui l'empêchent (in-compétence interne, 0 budget évolution, absence de conduite de changement, règlementation, support éditeur tiers, etc.) j'ai bien conscience de tout ça pour l'avoir vécu.

Mais dans la large majorité des cas, le micro-service au sens large est largement bénéfique à terme pour toutes les parties prenantes exceptés certains métiers techniques spécialisés. De toute façon les infogérants, les intégrateurs et/ou éditeurs tiers qui ne suivront pas se feront larguer tôt ou tard, par ailleurs c'est pas pour rien qu'il y a des clouds qui se forment de partout, l'orientation du marché est très claire (et logique).
votre avatar
C'est pas par plaisir de faire de la conteneurisation et tout l'accompagnement du changement qui va avec mais par gain de productivité, argument le plus puissant pour le business.
Je réagissais à la base sur ce propos que tu as tenu :
Si ça pouvait pousser les entreprises à conteneuriser massivement, on en ressortirait grandit.
J'ai vécu ce genre de stratégie qui tenait plus du dogmatisme que de la réflexion. Et ça a donné de la merde. Ni plus, ni moins.
Et à ce moment-là, Kubernetes n'était pas encore sur toutes les lèvres comme un messie.
(lui aussi apporte son lot d'emmerdes en matière de MCO)
Le problème que tu évoques de non-suivi du middleware n'a rien à voir avec le sujet de conteneurisation puisque la problématique est strictement la même en virtualisation.
D'où le fait que je disais que la containerisation était le même lot d'emmerdes que les VM ;)

Quant au micro service, si l'application est un gros monolithe de l'enfer, la containeriser n'a aucun sens.

Moderniser une application, ça ne se fait pas en deux coups de cuillère à pot ou par l'application de principes basiques. Il faut évaluer toutes les couches pour lui trouver la meilleure architecture (infra, logicielle, applicative) et aussi évaluer le gap entre le point de départ et la cible. Typiquement, si l'appli ne supporte pas de faire des mises à jour progressives, que les composants ont tous un couplage fort, qu'elle repose sur une base de données bourrée de PL/SQL, et que changer la version d'un seul morceau fait s'effondrer le château de cartes (en résumé : les ERP de l'enfer qu'on trouve en entreprise), autant dire que la seule issue c'est une refonte complète.
Et à ce moment-là, la question du SaaS va se poser.
votre avatar
Effectivement ça me paraissait évidemment mais peut-être que j'aurais dû préciser dès le début "pourvu que ça pousse les entreprises à découper leurs applis en micro-service et conteneuriser massivement".
votre avatar
6 jours après mais tant pis.
surtout quand la workload n'est pas pensée pour.
Arg, Les pods "master" de certaines applications (coucou Jenkins) qui empêchent le drain normal ( sans forcer ) d'un node.
votre avatar
Il y a une question d'échelle, si tu as moins de 10 serveurs et qu'ils sont tous différents, les containers ne sont pas une bonne approche. Si tu as 20 vm's frontend toutes identiques et 200 vm microservices derrière, prend un kubernetes.
votre avatar
Je suis étonné de lire autant d'approximation dans un coin aussi tech. La VM c'est le contenu d'un conteneur + le système qui est tout sauf un petit morceau à gérer. Je te rejoins sur la tenue d'un cluster kubernetes, en revanche les petits workloads des sites lambdas (la plupart des projets des infogérants de base) peuvent se faire sur un simple docker swarm. Mais la suite logique du conteneur est évidemment d'utiliser un cloud provider.
J'ai poussé des clients à faire de l'ECS (aws donc) avec LB, lambda, RDS, S3 (bref du grand classique) et la CI qui va bien pour qu'ils poussent leur code applicatif, et bon dieu la gestion est bien plus simple, les applications encaissent parfaitement la charge et économie des DBA, SYS, network etc. Je peux vous garantir qu'ils ne reviennent pas en arrière.

PS : j'ai l'impression que les messages n'apparaissent pas en dessous de la personne à laquelle je réponds, ce qui peut créer de la confusion
votre avatar
PS : j'ai l'impression que les messages n'apparaissent pas en dessous de la personne à laquelle je réponds, ce qui peut créer de la confusion
Oui, cette modification du comportement des commentaires est assez désagréable. On ne comprends plus à quel commentaire répond un autre. En espérant que le comportement précédent revienne.
votre avatar
Je suis étonné de lire autant d'approximation dans un coin aussi tech. La VM c'est le contenu d'un conteneur + le système qui est tout sauf un petit morceau à gérer.
:keskidit:

On a pas du se comprendre,
Tu dis, en gros, que tout le monde utilise et / ou developppe des applications containeurisées et tout ira beaucoup mieux.
Ce à quoi je répond, non, ca dépend de
- la maturité des équipes dans les techno de conteneurisation ( pour développer et pour maintenir les outils comme K8S)
- de la complexité à conteneurise une application ( les application qui ont été rentrer dans des conteneur au chausse pieds + marteaux ce sont les pire pour les (admin des) cluster K8S/OCP.
- de ton "environement" au sens large, par exemple pour du temps réel pas de conteneurisation.
- ...

J'ai poussé des clients à faire de l'ECS (aws donc) avec LB, lambda, RDS, S3 (bref du grand classique) et la CI qui va bien pour qu'ils poussent leur code applicatif, et bon dieu la gestion est bien plus simple, les applications encaissent parfaitement la charge et économie des DBA, SYS, network etc.
:roule2:
économie des DBA, SYS, network etc.
:non: :non: :non:

Ca c'est un coups à se retrouver avec un opérateur PostgreSQL-Zalando configuré comme un pieds, ou avoir un /29 pour le réseaux des nodes, ou des remarques : " je capte pas, j'arrive pas à joindre la serveur distant en ssh alors que mes ping/traceroute fonctionnent".
Oui c'est du vécu, Oui à la base je suis AdminSys (ou affilié) :)



+1 pour le PS.
votre avatar
Je vois plus d'échappement de conteneurs que de machines virtuelles.
votre avatar
Il faut bien entendu paramétrises son environnement correctement. Le propre des containers est de consommer des ressources de la machine hôte de manière transparente, du coup un environnement mal ou pas configuré pour la sécurité sera une passoire.
votre avatar
Je parlais d'échappement exploitant des failles sur le processus du service qui tourne en général en root. Je comprends que je ne m'étais pas étendu dans mon message, c'était implicite car je pensais que c'était connu plus largement.
votre avatar
C'était aussi de ça que je parlais. Les containers sont par nature moins isolés que les VM à pas mal d’égards, à moins de configurer son environnement correctement.

Ceux qui font tourner les containers systématiquement comme root n'ont de toutes façons rien à faire en milieu professionnel.

Maintenant si on utilise un système d'exécution de containers mature et en faisant attention à la sécurité, il y a beaucoup moins de risques.
votre avatar
Ce que tu dis n'a strictement aucun sens. ESX et Openshift sont deux produits différents et répondent à des besoins différents. Tu peux lancer plusieurs applications sur une VM sans conteneur, tu peux lancer des conteneurs dans une VM... Les deux produits n'ont juste rien à voir entre eux.

Il y a des applications qui ne sont pas "conteunerisable". Accès réseau, besoin de modules kernel spécifiques, applications/cluster très lié au hostname, accès à du hardware spécifique, ... Sans oublier les applications nécessitant du stockage persistant comme les bases de données. Pas non plus possible de debug avec strace ou tcpdump sans donner accès à l'OS sous les conteneurs...

Concernant l'administration système et le patch management, à partir du moment ou celui-ci a été rendu automatique et est correctement réfléchi, 200 ou 30000 VMs, ca n'a plus vraiment d'importance. A moins que tu fasses de l'administration à la main? ouch

Virtualisation et conteneurisation sont des outils, pas des finalités.
votre avatar
Réponse inutile, non seulement ça ne contredit en rien ce que j'ai dit mais en plus j'ai déjà évoqué le fait que tout n'est pas conteneurisable (= micro-architecturable) mais la plupart oui. Les bases de données (notamment nosql) sont parfaitement conteneurisables, là par contre je ne comprends pas l'exemple mais peu importe.

"à partir du moment ou celui-ci a été rendu automatique et est correctement réfléchi"
-> Pour avoir bossé de la PME du coin au GAFAM ce n'est jamais le cas. Et pour que ça tende vers ce stade il y a un coût de maintenance absolument non négligeable. Faut ouvrir les yeux à un moment, la percée forte des cloud provider vient exactement du fait que les DSI en ont ras la casquette de dépenser du temps et de la compétence spécialisée quand un autre acteur le fait mieux et pour moins cher.
votre avatar
Si une DSI ne voit pas l’intérêt de dépenser du temps et de l'argent dans l'industrialisation de son administration système, pourquoi elle le ferait dans l'industrialisation du cycle de vies des conteneurs qui est tout autant, si ce n'est plus, important?

J'administre au quotidien des milliers de VMs et orchestrateurs de conteneurs dont je n'ai pas la main sur les déploiements. Ce que j'en vois, c'est surtout que le conteneur est un cache misère dans la plupart des cas. Et c'est pour cette raison que je te rentre dedans quand je te lis: "Certainement par plaisir de se taper le patch management"

Des OS correctement géré tu peux, facilement, en tant qu'administrateur système, garantir que les failles de sécu du kernel, des lib, ainsi que tous les packages fourni par l'OS sont patché, la plupart du temps sans reboot.

Concernant les bases de données nosql dans des conteneurs, ce n'est pas le problème, tu peux aussi très bien lancer une base sql dans un conteneur...
Le soucis, c'est qu'un conteneur n'est pas fait pour avoir du stockage persistant. De façon général, une bdd stocke en local, donc plus de pod = plus data.

Ah moins que tu montes du stockage persistant dans des pods, ce qui est une grosse connerie technique pour répondre au besoin "one size fits all", autrement dit: du "tout conteneur".

Le conteneur, ca peut sincèrement être génial dans certain cas métier précis, avec le développement adapté, et uniquement quand tout est industrialisé, jusqu'au patch management.
Il n'y a pas de miracle, ni de magie. Les conteneurs, ça simplifie juste le boulot de sysadmin et déporte le problème de lifecycle sur les devops, voire pire, les dev... (ps: je n'ai rien contre les devs, juste qu'ils n'ont en général pas cette sensibilité HA et vision archi/infra, qu'on les admins sys)

"les DSI en ont ras la casquette de dépenser du temps et de la compétence spécialisée quand un autre acteur le fait mieux et pour moins cher."
Tu mélanges encore tout. Les clouds providers fournissent aussi bien de l'orchestration de conteneurs, que de la VM. Si une DSI veut passer d'une infra on prem à une infra cloud pour ne plus avoir à gérer du hardware, pas de problème... mais ca n'a aucun rapport avec les VMs VS conteneurs, tu peux très bien faire du Kubernetes, de l'Openshift ou tout autre techno d'orchestration on prem... ou de la VM chez AWS.
votre avatar
Ah moins que tu montes du stockage persistant dans des pods, ce qui est une grosse connerie technique pour répondre au besoin "one size fits all", autrement dit: du "tout conteneur".
Puis-je te demander pkoi c'est une "connerie technique" ? Quel est le soucis ?
votre avatar
J'utilise VMware Player personnellement et maintenant Workstation vu qu'il est devenu gratuit depuis le rachat. Eh ben pour télécharger les nouvelles versions, c'est une méga-purge, il m'a juste fallu 2h pour y arriver. Il faut un compte et une adresse postale valide, (j'ai mis un adresse yopmail et une vraie adresse postale mais pas la mienne), mais pour l'adresse postale rien ne te l'indique, tu n'as juste pas accès au lien avec une erreur sans aucun rapport. J'ai du chercher des expériences d'autres utilisateurs pour le savoir et comprendre où il fallait la rentrer, et attendre une vérification manuelle. Et même comme ça il y a plusieurs bugs à contourner et problèmes d'ergonomie à comprendre.

Jamais vu un truc aussi à chier, on voit bien que tu es chez un mastodonte B2B avec leurs segmentation, leurs procédures à la con et leurs logiciels "métier" antiques, et que tu es juste censé être une entreprise avec un contact chez eux pour te dire où cliquer.
votre avatar
Je ne suis pas convaincu de la présence d'une vérification manuelle parce que... j'ai mis une vraie rue, mais aucun numéro (je ne veux nuire à personne) et ça fonctionne. Au pire j'aurai mis un numéro fantôche pour tester.

A cette date il est toujours difficile d'obtenir la WPro car on n'est pas « entitled ». Il faut passer directement par ce lien et se logger.

La version 17.6 ne s'installe pas sur les installations non-US sans passer par cette astuce de part un bug.
votre avatar
Une vraie rue et pas de numéro ça peut tout à fait passer, c'est pas inhabituel. Et pour la vérification manuelle c'est juste que c'était marqué et que j'ai du attendre (bon, pas longtemps).

Enfin ce site n'est juste pas utilisable pour un particulier qui veut juste télécharger ma version gratuite. J'espère que les mises à jour intégrées au logiciel fonctionnent sans repasser par le site sinon je suis pas prêt de les installer de si tôt.

Pas eu de souci d'installation sur Windows français pour ma part.
votre avatar
Merci pour l'astuce pour la 17.6 non-US : j'ai pu télécharger VMware par un lien public (car mon compte Broadcom est HS), et j'ai bien dû ajouter les groupes avec noms anglais (qui n'existent pas dans un Windows français) pour que l'upgrade passe.
votre avatar
Pour ma part, petit client VMware Workstation Pro ; mon compte avec ma licence n'a jamais été migré correctement chez Broadcom, et impossible de joindre quelqu'un (mail ou autre) pour avoir une réponse, et pouvoir télécharger les nouvelles versions.

Broadcom c'est vraiment une purge.

(déjà vécu sur Ghost Solution Suite, qui est pratiquement impossible à acheter, alors qu'ils continuent de faire des mises à jour) - ma licence Broadcom Ghost a expiré il y a quelques mois, et impossible à renouveler.

Bref ; j'espère qu'ils ne vont pas massacrer VMware Workstation Pro qui est ultra pratique pour faire des tests (en tant que technicien) ; parce que se taper VirtualBox... j'y ai déjà goûté, et c'est pas la même qualité ni même stabilité (sur Windows).
votre avatar
Quand je vois VMware, je me dis surtout "qu'est-ce que c'est vieux"... Ok, la partie virtualisation est bonne, mais la partie orchestration, les API, ... c'est vieux... très vieux...

Rien que l'ordonnancement des vm est à pleurer, pas de gestion de clusters hétérogènes, pas de détection de fonctionnalités pour guider l'ordonnancement, on gaspille de la capacité non mobilisable comme si les serveurs poussaient dans les arbres, ... et je ne vais pas m'étendre sur la formulation des règles d'affinité ou d'anti-affinité, c'est carrément vétuste...

Je ne comprend pas comment ce produit est toujours si important, pourquoi les entreprises se rabattent si souvent dessus sans regarder la concurrence... D'un point de vue design fonctionnel, c'est mort
votre avatar
| "qu'est-ce que c'est vieux"... Ok, la partie virtualisation est bonne

Et voilà. C'est vieux donc connu et très bien intégré, ça marche franchement bien pour la virtu et jusqu'à maintenant les coûts de fonctionnement étaient compétitifs face à une migration. On parle Du socle technique quand même.
Nous sommes désormais en train d'étudier les concurrents vu la douille qu'on s'est prise mais même en partant sur de l'open source avec que du support, la transition va être couteuse en temps et en risque.
Donc c'est le genre de décision ou souvent le status quo prévaut.
Cela dit, perso je remercie Broadcom, c'était justement le coup de pied nécessaire pour déranger ce fameux status quo et j'avais envie de tester les concurrents. :D
votre avatar
La virtualisation est bonne, mais les API, les concepts d'orchestration, ça traîne des casseroles vieilles de 20 ans, et je connais bien, j'y étais, et j'ai même été certifié il y a 15 ans... du coup quand je me retrouve avec un vmware moderne en main, une des première choses que je me dis c'est 'putain ils en sont toujours là, ils n'ont toujours pas corrigé xyz, ce truc est toujours aussi pénible'

Et ces limitations se ressentent dans les contraintes que cela crée, surtout pour les problèmes de continuité et les designs de clusters pour les centres de calcule.

Alors ok, ça marche bien, mais vu qu'ils ne se sortent pas beaucoup les doigts du cul pour faire évoluer le produit, j'aurais tablé sur une baisse de prix plutôt qu'une hausse. VMware devrait être vendu dans les bacs de DVD à 1,5€ genre films avec Mario Van Peebles.
votre avatar
Parce qu'aux entreprises, on vend de la stabilité, du rendement et des compétences, pas des technologies modernes. Par stabilité, j'entends stabilité dans le temps, sans devoir repartir sur une transition qui fait toujours un peu peur.

Et surtout, franchement pour la plupart des entreprises, la virtualisation c'est quand même plus simple. Souvent, ils sous-traitent une bonne partie de l'applicatif à plusieurs ESN, qui demandent chacune une ou plusieurs VM et quelques VLAN sur l'infrastructure. La force de l'habitude…
votre avatar
Je connais des entreprises qui font encore du cobole et ont des mainframes ... le fait que les entreprises veuillent de la stabilité est parfaitement acceptable et raisonnable, maintenant, ayant programmé des solutions d'automatisation utilisant les API de vsphere, et ayant vu de nombreuses entreprises incapables d'avoir un DR correct avec cet dernier, je m'interroge sur l'irréformabilité de la solution.
Si VCenter évoluait un peu, que l'on avait de l'ordonnancement moderne, que certains concepts étaient revus, bref, si c'était un produit vivant, je ne critiquerais pas tant, mais force est de constater que chez vmWare, l'innovation s'est surtout située au niveau des modèles de facturation (on se rappellera il y a quelques années quand ils avaient voulu facturer non plus sur base du nombre de sockets ou de coeurs mais aussi sur base de la quantité de ram)

La grogne monte contre VMware (Broadcom) : AT&T, Orange et Thales vont en justice

Fermer